<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>The JE Application</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Getting Started with Berkeley DB Java Edition" />
    <link rel="up" href="introduction.html" title="Chapter 1. Introduction to Berkeley DB Java Edition" />
    <link rel="prev" href="introduction.html" title="Chapter 1. Introduction to Berkeley DB Java Edition" />
    <link rel="next" href="restore.html" title="JE Backup and Restore" />
  </head>
  <body>
    <div class="navheader">
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">The JE Application</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 1. Introduction to Berkeley DB Java Edition </th>
          <td width="20%" align="right"> <a accesskey="n" href="restore.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="applicationoverview"></a>The JE Application</h2>
          </div>
        </div>
      </div>
      <div class="toc">
        <dl>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#dbIntro">Database Environments</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#key-data">Key-Data Pairs</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#storing-intro">Storing Data</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#duplicatesintro">Duplicate Data</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#replacedeleteIntro">Replacing and Deleting Entries</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#secondary">Secondary Keys</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#transactionIntro">Transactions</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#resourcesIntro">JE Resources</a>
            </span>
          </dt>
          <dt>
            <span class="sect2">
              <a href="applicationoverview.html#applicationConsiderations">
        Application Considerations
       </a>
            </span>
          </dt>
        </dl>
      </div>
      <p>This section provides a brief overview to the major concepts and
    operations that comprise a JE application. This section is concluded with a summary of the decisions that
    you need to make when working with JE.</p>
      <p>
    Note that the core JE classes are all contained in the <code class="literal">com.sleepycat.je</code> package.
    In addition, this book describes some classes that are found in <code class="literal">com.sleepycat.je.bind</code>.
    The bind APIs are used for converting Java objects in and out of <code class="literal">byte</code> arrays.
 </p>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="dbIntro"></a>Database Environments</h3>
            </div>
          </div>
        </div>
        <p>
              Regardless of the JE API that you use, your data is
              stored in databases. If you use the DPL, you do not manage
              these databases directly; rather, they are managed for you by
              the API. On the other hand, if you use the lower-level JE
              APIs, then you must manage databases directly. This is not
              difficult to do as it mostly involves opening and closing the
              databases, giving them names, and so forth. See 
                <a class="xref" href="databases.html" title="Chapter 7. Databases">Databases</a> 
              for more
              information.
      </p>
        <p>
            That said, JE always requires you to use a
            <span class="emphasis"><em>database environment</em></span>. Database
            environments provide an unit of encapsulation for one or more
            databases. Environments correspond to a directory location on
            disk, and in them you will find all the files in use by JE.
            Environments are also used to manage JE resources such as
            transactions.
      </p>
        <p>
              To use a database environment, it must first be created and then
              opened. In order to create a database environment, the
              directory location in which it resides must already exist.
      </p>
        <p>
              You open a database environment by instantiating an 
              <code class="classname">Environment</code> object. Your 
              <code class="classname">Environment</code> instance is called 
              an <span class="emphasis"><em>environment handle</em></span>.
      </p>
        <p>

              Once you have opened an environment, what you do with it
              depends on the nature of your application; that is, the
              JE API you are using and whether you are using advanced
              features such as transactions. (See  
              <em class="citetitle">Berkeley DB, Java Edition Getting Started with Transaction Processing</em> 
              for details on using
              transactions). However, at a minimum you will always have to
              open your environment before you can access your data stored
              in JE. Also, before you end your application you should
              always close your environment.
      </p>
        <p>
        Environments are described in greater detail in <a class="xref" href="env.html" title="Chapter 2. Database Environments">Database Environments</a>.
      </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="key-data"></a>Key-Data Pairs</h3>
            </div>
          </div>
        </div>
        <p>
                    JE stores and retrieves data using
                    <span class="emphasis"><em>key-data pairs</em></span>. The
                    <span class="emphasis"><em>data</em></span> portion of this is the data
                    that you have decided to store in JE for future
                    retrieval. The <span class="emphasis"><em>key</em></span> is the
                    information that you want to use to look up your
                    stored data once it has been placed inside a JE
                    database.
            </p>
        <p>
                    For example, if you were building a database that
                    contained employee information, then the
                    <span class="emphasis"><em>data</em></span> portion is all of the
                    information that you want to store about the employees:
                    name, address, phone numbers, physical location, their
                    manager, and so forth.
            </p>
        <p>
                    The <span class="emphasis"><em>key</em></span>, however, is the way that
                    you look up any given employee. You can have more than
                    one key if you wish, but every record in your database must have a
                    primary key. If you are using the DPL, then this key must be unique; that is,
                    it must not be used multiple times in the database. However, if you are using
                    the base API, then this requirement is relaxed.  See
                    <a class="xref" href="applicationoverview.html#duplicatesintro" title="Duplicate Data">Duplicate Data</a> for more
                    information.
            </p>
        <p>
                    For example, in the case of an employee database, you would probably use
                    something like the employee identification number as the primary key as this
                    uniquely identifies a given employee.
            </p>
        <p>
                    You can optionally also have secondary keys that represent indexes
                    into your database. These keys do not have to be unique
                    to a given record; in fact, they often are not. For
                    example, you might set up the employee's manager's name
                    as a secondary key so that it is easy to locate all
                    the employee's that work for a given manager.
            </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="storing-intro"></a>Storing Data</h3>
            </div>
          </div>
        </div>
        <p>
                    How you manage your stored information differs
                    significantly, depending on which API you are using.
                    Both APIs ultimately are doing the same thing, but the
                    DPL hides a lot of the details from you.
            </p>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title"><a id="dplstore"></a>Storing Data in the DPL</h4>
              </div>
            </div>
          </div>
          <p>
                    The DPL is used to store Java objects in an
                    underlying series of databases. These databases are
                    accessed using an <code class="classname">EntityStore</code>
                    class object.
            </p>
          <p>
                    To use the DPL, you must decorate the classes you
                    want to store with Java annotations that identify them
                    as either an <span class="emphasis"><em>entity class</em></span> or a
                    <span class="emphasis"><em>persistent class</em></span>.
            </p>
          <p>
                Entity classes are classes that have a primary key, and
                optionally one or more secondary keys. That is, these
                are the classes that you will save and retrieve directly
                using the DPL. You identify an entity class using the
                <code class="literal">@Entity</code> java annotation.
            </p>
          <p>
                    Persistent classes are classes used by entity classes.
                    They do not have primary or secondary indices used for
                    object retrieval. Rather, they are stored or retrieved
                    when an entity class makes direct use of them. You
                    identify an persistent class using the
                    <code class="literal">@Persistent</code> java annotation.
            </p>
          <p>
                    The primary key for an object is obtained from one of the class' data members.
                    You identify which data member to use as the primary key using the
                    <code class="literal">@PrimaryKey</code> java annotation.
            </p>
          <p>
                    Note that all non-transient instance fields of a
                    persistent class, as well as its superclasses and
                    subclasses, are persistent. Static and transient fields
                    are not persistent. The persistent fields of a class
                    may be private, package-private (default access),
                    protected or public.
            </p>
          <p>

                    Also, simple Java types, such as
                    <code class="classname">java.lang.String</code> and
                    <code class="classname">java.util.Date</code>, are automatically handled as a
                    persistent class when you use them in an entity class;
                    you do not have to do anything special to cause these
                    simple Java objects to be stored in the
                    <code class="classname">EntityStore</code>.

            </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title"><a id="lowlevelstore"></a>Storing Data using the Base API</h4>
              </div>
            </div>
          </div>
          <p>
                    When you are not using the DPL, both record keys and record data must be byte
                    arrays and are passed to and returned from JE using
                    <code class="classname">DatabaseEntry</code> instances.
                    <code class="classname">DatabaseEntry</code> only supports storage of Java byte arrays.
                    Complex objects must be marshaled using either Java serialization, or more
                    efficiently with the bind APIs provided with JE </p>
          <p> Database
                    records and <code class="literal">byte</code> array conversion are described in <a class="xref" href="DBEntry.html" title="Chapter 8. Database Records">Database Records</a>.
                </p>
          <p>
                        You store records in a <code class="classname">Database</code> by calling one of the
                        put methods on a <code class="classname">Database</code> handle.  JE
                        automatically determines the record's proper placement in the database's
                        internal B-Tree using whatever key and data comparison functions that are
                        available to it.
                </p>
          <p>
                        You can also retrieve, or get, records using the
                        <code class="classname">Database</code> handle.  Gets are performed by providing the
                        key (and sometimes also the data) of the record that you want to retrieve.
                </p>
          <p>
                        You can also use cursors for database puts and gets. Cursors are essentially
                        a mechanism by which you can iterate over the records in the database. Like
                        databases and database environments, cursors must be opened and closed.
                        Cursors are managed using the <code class="classname">Cursor</code> class.
                </p>
          <p>
                        Databases are described in <a class="xref" href="databases.html" title="Chapter 7. Databases">Databases</a>. Cursors
                        are described in <a class="xref" href="Cursors.html" title="Chapter 9. Using Cursors">Using Cursors</a>.
                </p>
        </div>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="duplicatesintro"></a>Duplicate Data</h3>
            </div>
          </div>
        </div>
        <p>
              If you are using the base API, then at creation time databases can be configured to
              allow duplicate data. Remember that JE database records consist of a key/data
              pair. <span class="emphasis"><em>Duplicate data</em></span>, then, occurs when two or more records have
              identical keys, but different data. By default, a <code class="classname">Database</code> does
              not allow duplicate data.
      </p>
        <p>
              If your <code class="classname">Database </code> contains duplicate data, then a simple
              database get based only on a key returns just the first record that uses that key.  To
              access all duplicate records for that key, you must use a cursor.
      </p>
        <p>
              If you are using the DPL, then you can duplicate date using
              secondary keys, but not by using the primary key. For more information, see
                <a class="xref" href="getmultiple.html" title="Retrieving Multiple Objects">Retrieving Multiple Objects</a>.
      </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="replacedeleteIntro"></a>Replacing and Deleting Entries</h3>
            </div>
          </div>
        </div>
        <p>
              If you are using the DPL, then replacing a stored entity object simply consists of
              retrieving it, updating it, then storing it again. To delete the object, use the
              <code class="methodname">delete()</code> method that is available on either its primary or
              secondary keys. If you use the <code class="methodname">delete()</code> method available on
              the secondary key, then all objects referenced by that key are also deleted.
              See <a class="xref" href="dpl_delete.html" title="Deleting Entity Objects">Deleting Entity Objects</a>
              for more information.
      </p>
        <p>
              If you are using the base API, then how you replace database records depends on whether
              duplicate data is allowed in the database.
      </p>
        <p>
              If duplicate data is not allowed in the database, then simply calling
              <code class="methodname">Database.put()</code> with the appropriate key will cause any
              existing record to be updated with the new data. Similarly, you can delete a record by
              providing the appropriate key to the <code class="methodname">Database.delete()</code>
              method.
      </p>
        <p>
              If duplicate data is allowed in the database, then you must position a cursor to the
              record that you want to update, and then perform the put operation using the cursor.
      </p>
        <p>
            To delete records using the base API, you can use either <code class="methodname">Database.delete()</code> or
            <code class="methodname">Cursor.delete()</code>. If duplicate data is not allowed in your
            database, then these two method behave identically. However, if duplicates are allowed
            in the database, then <code class="methodname">Database.delete()</code> deletes every record
            that uses the provided key, while <code class="methodname">Cursor.delete()</code> deletes just
            the record at which the cursor is currently positioned.
      </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="secondary"></a>Secondary Keys</h3>
            </div>
          </div>
        </div>
        <p>
                    Secondary keys provide an alternative way to locate information stored in
                    JE, beyond that which is provided by the primary key. Frequently secondary
                    keys refer to more than one record in the database. In this way, you can find
                    all the cars that are green (if you are maintaining an automotive database) or
                    all the people with brown eyes (if you are maintaining a database about people).
                    In other words, secondary keys represent a index into your data.
            </p>
        <p>
                    How you create and maintain secondary keys differs significantly, depending on
                    whether you  are using the DPL or the base API.
            </p>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title"><a id="secondarydpl"></a>Using Secondaries with the DPL</h4>
              </div>
            </div>
          </div>
          <p>
                            Under the DPL, you declare a particular field to be a secondary key by
                            using the <code class="literal">@SecondaryKey</code> annotation. When you do this,
                            you must declare what kind of an index you are creating. For example,
                            you can declare a secondary key to be part of a
                            <code class="literal">ONE_TO_ONE</code> index, in which case the key is unique to
                            the object. Or you could declare the key to be
                            <code class="literal">MANY_TO_ONE</code>, in which case the key can be used for
                            multiple objects in the data store.
                    </p>
          <p>
                            Once you have identified secondary keys for a class, you can access
                            those keys by using the <code class="methodname">EntityStore.getSecondaryIndex()</code>
                            method.
                    </p>
          <p>
                            For more information, see <a class="xref" href="dplindexcreate.html#dplsecondaryidxdecl" title="Declaring Secondary Indexes">Declaring Secondary Indexes</a>.
                    </p>
        </div>
        <div class="sect3" lang="en" xml:lang="en">
          <div class="titlepage">
            <div>
              <div>
                <h4 class="title"><a id="secondarybaseapi"></a>Using Secondaries with the Base API.</h4>
              </div>
            </div>
          </div>
          <p>
                    When you are using the base API, you create and maintain secondary keys using a
                    special type of a database, called a <span class="emphasis"><em>secondary database</em></span>.
                    When you are using secondary databases, the database that holds the data you are
                    indexing is called the <span class="emphasis"><em>primary database</em></span>.
                </p>
          <p>
                        You create a secondary database by opening it and associating it with an
                        existing primary database. You must also provide a class that generates the
                        secondary's keys (that is, the index) from primary records.  Whenever a
                        record in the primary database is added or changed, JE uses this class
                        to determine what the secondary key should be.
                </p>
          <p>
                        When a primary record is created, modified, or deleted, JE automatically
                        updates the secondary database(s) for you as is appropriate for the
                        operation performed on the primary.
                </p>
          <p>
                    You manage secondary databases using the
                    <code class="classname">SecondaryDatabase</code> class.  You identify how to create keys
                    for your secondary databases by supplying an instance of a class that implements
                    the <code class="classname">SecondaryKeyCreator</code> interface.
                </p>
          <p>
                    Secondary databases are described in <a class="xref" href="indexes.html" title="Chapter 10. Secondary Databases">Secondary Databases</a>.
                </p>
        </div>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="transactionIntro"></a>Transactions</h3>
            </div>
          </div>
        </div>
        <p>
              Transactions provide a high level of safety for your JE operations by allowing
              you to manage one or more operations as if they were a single unit of work.
              Transactions provide your JE operations with recoverability, atomicity, and
              isolation.
      </p>
        <p>
              Transactions provide recoverability by allowing JE to undo any
              transactional-protected operations that may have been in progress at the time of an
              application or system failure.
      </p>
        <p>
              Transactions provide atomicity by allowing you to group many operations into
              a single unit of work. Either all operations succeed or none of them do. This means
              that if one write operation fails for any reason, then all other writes contained
              within that transaction also fail. This ensures that the database is never partially
              updated as the result of an only partially successful chain of read/write operations.
      </p>
        <p>
              Transactions provide isolation by ensuring that the transaction will never write to a
              record that is currently in use (for either read or write) by another transaction.
              Similarly, any record to which the transaction has written can not be read outside of
              the transaction until the transaction ends. Note that this is only the default
              behavior; you can configure your <code class="classname">Database</code>,
              <code class="classname">Cursor</code>, or <code class="classname">Transaction</code> handle to relax
              its isolation guarantees. 
      </p>
        <p>
        Essentially, transactional isolation provides a transaction with the same unmodified view of the
        database that it would have received had the operations been performed in a single-threaded application.
      </p>
        <p>
              Transactions may be long or short lived, they can encompass as many 
              operations as you want, and (if using the base API) they can span databases 
              so long as all participating databases reside in the same environment.
      </p>
        <p>
              Transaction usage results in a performance penalty for the application because they
              generally require more disk I/O than do non-transactional operations. Therefore, while
              most applications will use transactions for JE writes, their usage is optional.
              In particular, processes that are performing read-only operations
              might not use transactions.  Also, applications that use JE for an easily
              recreated cache might also choose to avoid transactions.
      </p>
        <p>
        Using transactions with your JE applications is described in detail in the
        <em class="citetitle">Berkeley DB, Java Edition Getting Started with Transaction Processing</em> guide.
      </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="resourcesIntro"></a>JE Resources</h3>
            </div>
          </div>
        </div>
        <p>
        JE has some internal resources that you may want to manage. Most important of these is the in-memory cache.
        You should carefully consider how large the JE cache needs to be. If you set this number too low, JE will
        perform potentially unnecessary disk I/O which will result in a performance hit. If you set it too high, then
        you are potentially wasting RAM that could be put to better purposes.
      </p>
        <p>
        Note that the size that you configure for the in-memory cache is a maximum size. At application startup, the
        cache starts out fairly small (only about 7% of the maximum allowed size for the cache). It then grows as is
        required by your application's database operations. Also, the cache is not pinned in memory – it can be
        paged out by your operating system's virtual memory system.
      </p>
        <p>
            Beyond the cache, JE uses several background threads to clean
            the JE log files, to compress the database by removing unneeded
            subtrees, and to flush database changes seen in the cache to the backing data files. For the
            majority of JE applications, the default behavior for the background threads should be acceptable and you
            will not need to manage their behavior. Note that background threads are started no more than once per
            process upon environment open. 
      </p>
        <p>
        For more information on sizing the cache and on the background threads, see <a class="xref" href="administration.html" title="Chapter 12. Administering Berkeley DB Java Edition Applications">Administering Berkeley DB Java Edition Applications</a>.
      </p>
      </div>
      <div class="sect2" lang="en" xml:lang="en">
        <div class="titlepage">
          <div>
            <div>
              <h3 class="title"><a id="applicationConsiderations"></a>
        Application Considerations
       </h3>
            </div>
          </div>
        </div>
        <p>When building your JE application, be sure to think about the following things:</p>
        <div class="itemizedlist">
          <ul type="disc">
            <li>
              <p>What data do you want to store? What is best used for the
          primary key? What is the best representation for primary record data?
          If you are using the base API, think about the most efficient way to move your keys and data in and
          out of byte arrays. See <a class="xref" href="DBEntry.html" title="Chapter 8. Database Records">Database Records</a> for more information.</p>
            </li>
            <li>
              <p>Does the nature of your data require duplicate record support?
                  Remember that duplicate support can be configured only if you are using the base
                  API, and then only at database
          creation time. See <a class="xref" href="databases.html#DBOpen" title="Opening Databases">Opening Databases</a> for more information.</p>
              <p>If you are supporting duplicate records, you may also need to think
          about duplicate comparators (not just key comparators). See
          <a class="xref" href="comparator.html" title="Using Comparators">Using Comparators</a> for more information.</p>
            </li>
            <li>
              <p>What secondary indexes do you need? How can you compute your secondary indexes based on the data and
          keys stored in your primary database?
          Indexes are described in <a class="xref" href="indexes.html" title="Chapter 10. Secondary Databases">Secondary Databases</a>.</p>
            </li>
            <li>
              <p>What cache size do you need? See
          <a class="xref" href="cachesize.html" title="Sizing the Cache">Sizing the Cache</a> for information on how to size your cache.</p>
            </li>
            <li>
              <p>Does your application require transactions (most will).
          Transactions are described in the
          <em class="citetitle">Berkeley DB, Java Edition Getting Started with Transaction Processing</em> guide.
      </p>
            </li>
          </ul>
        </div>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="introduction.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="introduction.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="restore.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Chapter 1. Introduction to Berkeley DB Java Edition  </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> JE Backup and Restore</td>
        </tr>
      </table>
    </div>
  </body>
</html>
